感謝諸位鐵人參賽者大大的熱情文章

真的，我覺得我學習到很多東西。如果你現在到博客來去蒐尋，你會發現相比於 Python、Java、C#、Javascript這些熱門的程式語言，ElasticSearch/ELK基本上是沒有什麼專書。你能依靠的就只有官網上的英文文章，與網路上其他熱心人士所編寫的中文文章。今年 Elastic Co 很熱情的贊助了30天的試用期，我想換來的產出絕對是值得的。由於我是從9月1日就開始加入賽事，然後有很多參賽者是從9月中開始參賽，他們所書寫的文章，讓我發現了我自己一些弄錯的觀念，有助於我事後再去官網翻找最新的 API 文件。真的非常感謝他們

ELK學習地圖的主軸優先建議 ElasticSearch

我自己是在8月底與9月中各註冊了一個帳號進行學習。我想即使比賽結束後，我還是會設法將 ElasticSearch 觀念不足的部分給補齊。我有什麼地方學習的不夠好呢? 主要是在 mapping、全文蒐尋、布林運算、巢狀布林運算，這些在ElasticSearch中重要的部分。當然啦，就如之前文章說的要透過 Kibana 選單下的 Console 比較好用。並不是說資料視覺化不重要，還是一般人在 R 、Python 中，其實已經學習到了資料視覺化的技法。甚至有些公司，還會導入商業化的 BI 工具，像是 Tableau或是PowerBI，但是能做到全文蒐尋等特別功能的，放眼望去，ElasticSearch 的確就是首選。目前聽到很多業界的朋友，也是透過 ELK 打造在不同產業下情蒐系統。不過就像有鐵人賽的朋友說的，這東西學起來真的是有點"反人類"，不過也因此學起來後，在職場上的價值應該就會更高。畢竟每項工具都有它的專長，你可以用筷子吃牛排，但是有點小錢的情況下，你為什麼不去買個刀叉呢?

每天給自己一段讀書時間是有價值的

為了這次的參賽(真的是志在參加)，所以每天都要花點時間來寫寫程式，看看官網文章、讀讀其他參賽者費心整理後的心得。雖然自知在 ELK 技術領域上還有一大段的路要走。但是相比於9月1日那時滿滿的雄心壯志，現在一路跌跌撞撞，終於也知道了自己那邊不足，那邊需要再強化。就像別人說的，程式不是單純拿來看的，重點是要自己寫過想過，才會知道自己錯在什麼地方。提出一個解法不難，難的是在執行程式的過程中各種 bug 與例外處理，要如何將其重現與克服，那才是考驗一個程式設計師功力之所在。

多涉獵不同領域的鐵人賽文章

因為近來對於 Functional Programming 領域有很深的興趣，也設法在工作中加以運用。看到其他類別的鐵人賽選手，有針對此主題進行連續30天的發文；我想相關的文章，我會努力將其閱覽完畢的。也希望大家在工作之餘，不只針對自己的專業領域，最好是能在拓展更多的技術面向。

總之，多多向強者學習，行有餘力則引領新手，大家互相求成長!